簡單的定義是：以文字、表格及圖形說明專案計劃完成之後，所預期的產出結果。
寫的時侯大概的原則是「由大到小，由大方向到小細項」，以「建置人力銀行網站專案」為例，要定義範疇的方向可以參考下列簡例：
**目標：**公司拓展業務方向，提高獲利
**範圍：**在2008年第四季導入人力銀行網站
工作事項：

1. 決定預算及時程
2. 擬定專案計劃
3. 專案執行
4. 成果驗收
5. 上線運作
   交付項目：
6. 專案計劃書
7. 專案會議記錄
8. 驗收報告

以下是與範疇有關的一些名詞以及原則，這裡做個說明

**RFP：**Request for Proposal，較大型標案中，甲方會提供RFP給所有有意願承包的乙方當參考資料，RFP的內容主要是針對甲方所欲外包的工作，做更詳細的說明，乙方可以更清楚地評估自身承接標案的能力，並據以評估時程、成本之後，做出報價。
**RFI：**Request for Information，有些標案，甲方只知道要做什麼，但是細節不是很清楚，於是就會發出Rrequst for Information，向其他有相關專業知識的廠商詢問資料，將資料彙整之後，再寫成RFP。
**RFQ：**Request for Quotation，在各項先期溝通完成之後，甲方詢問乙方報價的動作

As-is, To-be 與 Gap
這是定義範疇時一種常用的方法，因為很簡單明瞭，As-is指的就是「現況」，To-be指的就是「未來」(即專案完成後的結果)，而Gap就是其中的差異。
以頂樓加蓋一間小工作室為例，As-is就是目前三層樓透天的房子，To-be就是三層樓的房子，頂樓有一間小工作室，Gap就是要蓋的那間小工作室。
IT界的專案中的As-is和To-be或許沒有這麼單純而簡單的定義，但是基本上這個方法可以讓許多人在短時間內了解到這個專案要做的是什麼，更甚至可以評估「值不值得這個錢」。

需要(need)與想要(want)
我本身的經驗多半是乙方，在專案前期過程，與甲方在談需求與定義範疇時，常常會用到這個方法，就是「需要」和「想要」，有時客戶講得天花亂墜、口沬橫飛，你就要適時的將他拉回現實世界，或者讓他做完夢之後，清楚地(一定要明確地)跟他溝通，他想要的是什麼，他需要的是什麼，以及你在這個專案打算承做的是什麼。每個人都想要一輛法拉利，但每個人只是需要一輛代步工具的自小客而已。

規模大小
專案規模大小是個吊詭的東西，要靠經驗去拿捏。規模太小賺不了什麼錢，規模太大又怕結不了案；規模太小客戶可能會看不上眼，規模太大客戶又可能不願意出那個錢。
對於IT界的專案，我的建議是，每個專案的時間最好不要超過三個月，以免夜長夢多。或許你會覺得：笑死人了，三個月的案子太小了吧。沒錯，我的經驗是，如果有大案子，就把他切成好幾個三個月的小案子去進行，最好連合約都能分開簽，例如：發射太空梭之第一階段(基地建設)、發射太空梭之第二階段(人員訓練)、發射太空梭之第三階段(太空梭建造)…等等。

模糊與明確
這個與專案規模一樣，同樣是變化萬千的東西，也要靠實戰去累積經驗。以乙方的角度出發，Sales與客戶談案子的時侯，範疇定得越模糊，越容易接到案子；而乙方後援部隊(技術團隊)卻希望範疇越明確越好，因為越明確越容易結案。

技術人最愛說的一句不該說的話
「只要定義清楚，我就做得出來」，我小時侯自恃甚高，也很愛講這句話，不知道天高地厚，人情世故，如今看遍浪花淘盡英雄淚。在此奉勸各位，這句話少說為妙。